如何决定使用何种虚拟化技术

作者：David Pipes

如何衡量安全、架构和组织方面的需求以确定何种虚拟化技术最合适。

2012 年 4 月发布

当需要更新硬件时，需要将一些原本在自己的硬件中运行自如的负载整合到具有虚拟环境的系统上。但是，虚拟化方法多种多样，您如何进行选择？例如，Oracle Solaris 允许您创建虚拟网络，以及虚拟存储。您可以随意地为负载分配内存和 CPU。Oracle Solaris 区域（先前称为 Oracle Solaris 容器）允许您虚拟化整个系统。您还可以选择不同的虚拟机管理程序。SPARC 和 x86 平台中的硬件虚拟化方法又如何？它们如何让您多了一些选择，您应在什么情况下使用它们？

我更关心的是负载而不是技术。我问自己的第一个问题是：需要整合负载还是隔离负载？

负载整合只是意味着将负载合并到同一平台上的同一操作系统实例中。这是一种什么样的虚拟化呢？简而言之，这不是虚拟化。这是整合。如果只需要整合，为什么要虚拟化？Oracle Solaris 有许多工具允许您整合负载并使其在系统中的资源占用彼此隔离。项目可以保持用户组不进入彼此的文件和进程。公平共享调度通过让系统中的每个作业不占用过多的 CPU 资源而允许它们共存于同一个系统中。如果负载可以在系统上共存，且用户仅限于自己的区域，那为什么除了将其整合到同一系统上之外还需要做别的呢？有时，对于如何虚拟化的答案是“实际上您不需要。”

但假如存在安全、架构或组织方面的需求，这些需求要求各种负载之间保持隔离。在这种情况下，Oracle Solaris 提供了出色的解决方案，该方案内置在内核中且系统开销极低。这就是 Oracle Solaris 区域，它允许您创建虚拟系统，在用户看来，这个虚拟系统就像一个真实、独立的硬件平台。该技术带来安全隔离和资源隔离，它允许停止、启动和处理负载，而不会干扰系统上的任何其他组。它是安全、可伸缩的，具有出色的性能。（Oracle 使用 Oracle Solaris 区域运行一些公共基准测试。）而且它无需额外成本即可使用。

甚至提供了工具以支持系统中的 Oracle Solaris 区域管理，允许克隆区域、创建快照、迁移区域及其他任务。这些工具可以从 Oracle Enterprise Manager 模块访问，也可以从命令行访问。

Oracle Solaris 区域最少可以只使用一个硬件线程来创建（每个硬件线程是一个虚拟 CPU，因为它们向系统报告自身），但实际上，它们应包括足够的 CPU 资源以确保可以完成作业。系统中的区域越多，就应对所有这些区域是否有足够的资源给予更多的规划和考虑。RAM 通常是最大的限制因素，因而在将负载整合到 Oracle Solaris 区域时，应首先考虑这一因素。

但 Oracle Solaris 区域确实需求每个区域共享一个内核。尽管这不是缺点，但在整合很重要的场合还是有些影响的。系统上的所有 Oracle Solaris 区域将共享全局区域中安装的操作系统版本和补丁。非全局区域将不能控制硬件设备或内核本身。这些限制可能不适合高度整合的环境，即便 Oracle Solaris 区域具有灵活性并且系统开销极低。另外，Oracle Solaris 区域不能实时迁移。如果实际情况需要在同一系统上运行不同 版本的 Oracle Solaris，或者有时需要实时迁移环境，则要考虑下一种方法。

在 SPARC T 系列系统上，下一个可选方法是 Oracle VM Server for SPARC。Oracle Solaris 区域实际上并不使用虚拟机管理程序（如 VMware 或其他虚拟化软件），正是因为这个原因它们对性能的影响很小。Oracle VM Server for SPARC 确实有一个虚拟机管理程序，但已投入了许多工作来最小化它 — 它不是一个一应俱全的类型 1 管理程序（如 VMware）。因此，它的系统开销也很低。它还比重量级虚拟机管理程序更安全一些（由于它开始时小极了），并且相对较易于维护。

由于 Oracle VM Server for SPARC 是基于虚拟机管理程序的，它允许系统上的每个实例运行不同版本的 Oracle Solaris 10 或 11，当不同组还需要不同补丁级别的操作系统时，它是非常理想的选择。Oracle VM Server for SPARC 甚至支持在其中使用资源管理和 Oracle Solaris 区域（尽管后一种情况中某些软件可能有许可问题 — 明确地说。）随着时间的推移，可以根据需要添加 CPU、内存和存储资源以满足变化的负载要求。

比起 Oracle Solaris 区域，Oracle VM Server for SPARC 需要更多的规划，尤其是在容量增长方面，因为需要对是否虚拟化所有 I/O 并创建复制 I/O 域以实现可靠性以及其他类似考虑事项做出选择。但这里我们将坚持站在高级别上。

如果需要不同版本的操作系统，Oracle VM Server for SPARC 是 SPARC T 系列系统的理想选择。粒度达到硬件线程级别，但出于各种原因，开始时最好考虑将一个或多个核的单元用于 Oracle VM Server。（这里我们不深入探讨另一篇文章的一个主题，只是考虑每个核不仅提供 8 或 16 个线程用于虚拟系统，还允许关联 FPU 和 Crypto 单元轻松可供虚拟域使用。这意味着两个 Oracle VM for SPARC 环境不必利用在同一物理资源上调度线程的办法。）

对于 SPARC Enterprise M 系列系统，可用的技术名为“动态域”。该技术提供传统的系统硬件分区。CPU 模块和 RAM 以及 I/O 资源由系统控制器（不是由虚拟机管理程序）分配，并且在新创建的域上单独运行一个操作系统实例。域相对缺乏灵活性，尽管如果经过恰当的域规划和配置，可以使资源转移使用。但域确实保持负载在物理上彼此独立，资源共享最小（共享通常仅发生在 I/O 板被分割的情况下）。该功能并不是任何软件虚拟机管理程序都可以提供的。缺点是什么？与基于软件的解决方案相比，主要是成本和相对缺乏灵活性。但是，在动态域内部可以运行 Oracle Solaris 区域和资源控制，因此在使用动态域时，可以提供额外级别的灵活性。

简要回顾一下，记住在本练习中我们的目标主要是整合。如果可能，最轻松、最低廉的负载虚拟化解决方案是只将这些负载合并到同一平台上。该方法的优点是高度灵活、易于实施，并且所需的额外维护工作很少。缺点是用户组之间安全性较低，这可能违反内部要求，而且，使用这种方法，人们始终会担心修补或更新一个软件包可能会影响系统上其他软件包的功能。另外，“通过堆叠进行整合”的环境不会像虚拟化那样可带来安全性和敏捷性的提升。

当操作系统中的资源和安全控制不足以满足需求或需要更多的业务敏捷性时，适于使用 Oracle Solaris 区域方法。这些区域的系统开销极低、安全隔离很强（它们甚至运行在多级安全 [MLS] 环境中），它们可以共享稀缺硬件资源，对用户而言如同实际系统，并且其引导各自独立。此外，Oracle Solaris 区域可以轻松迁移，可以在内部以内存速度通信，要想管理它们，有许多命令行和 GUI 工具可以选择。缺点是所有区域共享同一内核，因此它们也共享操作系统及其补丁级别。如果您需要在一个系统上使用不同的操作系统版本，Oracle Solaris 区域和资源隔离就不够了。

在这些情况下，需要考虑硬件域划分：SPARC T 系列系统上的 Oracle VM Server for SPARC 和 SPARC Enterprise M 系列系统上的动态域。这些技术提供了机箱内硬件隔离的所有传统优点，尽管 Oracle VM Server for SPARC 确实具有在硬件单元（如各个 CPU 和 RAM）内部共享的能力。但是，使用这些技术，对于 SPARC T 系列系统可能需要额外的规划和配置成本，对于 SPARC Enterprise M 系列系统可能需要额外的硬件成本。在有些配置中，Oracle VM Server for SPARC 可能会带来一些 I/O 开销，但不会达到 VMware 这样齐备的类型 1 虚拟机管理程序的开销程度。同时，它还具有将使用中的活动 Oracle VM Server for SPARC 域迁移到其他系统的重要功能。

最后 — 我们来快速、轻松地浏览一下全部使用场景：

• 需要整合？请尝试资源管理。
• 这还不够（通常出于安全或业务敏捷性的原因）？Oracle Solaris 区域适合大多数负载虚拟化需求，应始终 将其视为 Oracle Solaris 虚拟化的最佳选择（免费、安全、轻松、敏捷、高效 — 有什么不喜欢的？）。
• 仅在排除了 Oracle Solaris 区域技术之后考虑 Oracle VM Server for SPARC 和动态域作为主要可选方法 — 这不是因为 Oracle VM Server for SPARC 和动态域不好，而是因为 Oracle VM Server for SPARC 需要更多的配置和维护工作，而动态域技术可能硬件成本更高。但与只是将应用程序堆叠在服务器上相比，这些技术确实提供了更多的灵活性。

实际上，所有这些虚拟化场景比非虚拟化环境在安全性、灵活性和可伸缩性方面具有更多的选择。这是一个有趣的观察，本身值得讨论。

若想更多了解这一主题，请参阅 Jeff Victor、Jeff Savit、Gary Combs、Simon Hayler 和 Bob Netherton 的杰作《Oracle Solaris 10 System Virtualization Essentials》。尽管我参考了这一杰作，但以上分析基于我自己在此领域的经验，若有任何错误之处，都是我自己的，不是别人的。

关于作者

David Pipes 专门从事系统硬件和软件售前工作，自 1999 年起他一直是 Sun Microsystems 和 Oracle 的系统顾问，为美国卫生和公共服务部提供支持。在此之前，他曾作为系统管理员和问题解决者为各家政府和私营公司工作。1985 年他获得汉普郡学院学士学位。

通过 Facebook、Twitter 或 Oracle 博客关注我们。